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ABSTRACT 

While  there  is  a  considerable  body  of  scientific  knowledge  on  the  principles  for  designing 
simulations,  there  is  a  gap  in  translating  these  principles  into  the  pragmatics  for  designing 
large-scale,  distributed,  peer-to-peer  federated  simulations  at  the  coalition  level.  CAGE  IIIA 
successfully  implemented  a  fully  distributed,  federated  simulation  environment  that 
stimulated  each  Nations  C2  systems.  This  report  describes  the  Distributed  Simulation  Design 
methodology  that  was  developed  and  trialled  by  DSTO  during  the  CAGE  IIIA  experiment  to 
enable  the  pragmatics  of  designing  and  implementing  a  fully  distributed,  federated 
simulation  environment. 
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CAGE  IIIA  Distributed  Simulation  Design 

Methodology 

Executive  Summary 

The  Coalition  Attack  Guidance  Experiment  (CAGE)  IIIA  is  the  third  in  an  ongoing 
campaign  of  coalition  human-in-the-loop  experiments.  The  CAGE  Campaign 
Objective  6  is  to  "Improve  the  methodology  and  analysis  tools  for  scientific  analysis  of 
cross-boundary  issues  in  distributed  experimentation".  In  addition  Technical  Panel  8  of 
the  Joint  Systems  Analysis  group  under  The  Technology  Cooperation  Program  (TTCP 
JSA  TP8)  have  been  tasked  to  leverage  the  CAGE  campaign  to  develop  an  addendum 
to  the  Guide  to  Experimentation  (GUIDEX)  that  focuses  on  the  pragmatics  of 
distributed  experimentation  and  to  develop  a  distributed  simulation  design 
methodology. 

While  there  is  a  considerable  body  of  scientific  knowledge  on  the  principles  for 
designing  simulations,  there  is  a  gap  in  translating  these  principles  into  the  pragmatics  for 
designing  large-scale,  distributed,  peer-to-peer  federated  simulations  at  the  coalition  level 
[Jessee,  S.  et  al.,  2013d]. 

The  distributed  simulation  design  problem  confronting  a  fully  distributed,  federated 
simulation  environment  as  represented  by  the  CAGE  campaign  of  experiments  is  that 
there  is  no  central  design  authority,  but  rather  a  federation  of  systems  owned, 
developed  and  operated  by  each  nation  with  an  agreed  upon  purpose,  i.e.  an 
Acknowledged  System  of  Systems  (SoS)  [DoD  OSD  2008].  Standards  such  as 
Federation  Development  and  Execution  Process  (FEDEP),  Synthetic  Environment 
Development  and  Exploitation  Process  (SEDEP),  Distributed  Simulation  Engineering 
and  Execution  Process  (DSEEP)  and  Kweley  and  Wood  [Andreas  Tolk  et  al.  (2012)]  all 
assume  a  central  design  authority  and  thus  full  control  of  the  system  of  systems  (i.e.  a 
Directed  SoS  [DoD  OSD  2008])  that  result  from  the  federation. 

CAGE  IIIA  successfully  implemented  a  fully  distributed,  federated  simulation 
environment  that  stimulated  each  nation's  C2  systems.  Each  nation  was  responsible  for 
building  their  own  simulation  environment  for  their  area  of  operation.  The  national 
simulations  environments  were  then  federated  together  enabling  entities  to  move 
across  areas  of  operation  and  to  be  available  in  the  other  nation's  simulations.  The 
advantage  of  designing  a  distributed,  federated  simulation  environment  is  that  there 
are  no  dependencies  between  nations  for  simulation  services.  In  situations  where  a 
nation  is  off  the  network  during  experiment  conduct,  the  other  nations  can  continue 
functioning.  As  a  result  within  the  CAGE  environment  "there  is  a  fundamental 
requirement  to  ensure  each  nation  retains  control  of  their  simulations,  while  federating  at 
execution  time  in  a  peer-to-peer  manner". 
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Recommended  way  forward 

The  distributed  simulation  design  methodology  developed  through  CAGE  IIIA  and 
presented  in  this  report  has  demonstrated  sufficient  utility  and  robustness  that  it 
should  continue  to  be  used  and  developed  in  both  the  CAGE  campaign  of  experiments 
and  similar  exercises/ experiments  that  exploit  distributed  federated  simulations. 
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Tactical  Operations  Centre 
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VM 

Virtual  Machine 
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VMF 

Variable  Message  Fonnat 

XML 
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1.  Introduction 


The  Coalition  Attack  Guidance  Experiment  (CAGE)  IIIA  is  the  third  in  an  ongoing  series 
of  coalition  human-in-the-loop  experiments1.  CAGE  IIIA  was  a  coalition  supported, 
Australian  led  activity  conducted  28  October  -  8  November,  2013  with  distributed  in  situ 
military  participation  from  Australia  with  limited  participation  from  Canada  and  the  UK. 

The  CAGE  problem  domain  is  focused  on  a  joint  and  coalition  task  force  facing  battlespace 
integration,  synchronisation,  coordination  and  deconfliction,  joint  fires  system 
interoperability,  and  cross-boundary  control  issues  in  the  prosecution  of  dynamic  targets 
and  emergent  targets2. 

The  CAGE  II  and  IIIA  experiments  were  designed  and  conducted  as  large-scale, 
distributed,  peer-to-peer  federated  experiments  across  Australia,  Canada,  United 
Kingdom,  and  the  United  States.  While  there  is  a  considerable  body  of  scientific 
knowledge  on  the  principles  for  designing  simulations,  there  is  a  gap  in  translating  these 
principles  into  the  pragmatics  for  designing  large-scale,  distributed,  peer-to-peer  federated 
simulations  at  the  coalition  level  [Jessee,  S.  et  al.,  2013d]. 

1.1  Purpose  of  the  Report 

This  report  documents  the  distributed  simulation  design  methodology  (DSDM)  being 
developed  and  used  in  the  CAGE  campaign  of  experiments. 

Within  CAGE  there  is  no  central  design  authority,  but  rather  a  federation  of  systems 
owned,  developed  and  operated  by  each  nation  with  an  agreed  upon  purpose,  i.e.  a 
directed  System  of  Systems  (SoS)  [DoD  OSD  2008].  Standards  such  as  Federation 
Development  and  Execution  Process  (FEDEP)3,  Synthetic  Environment  Development  and 
Exploitation  Process  (SEDEP)4,  Distributed  Simulation  Engineering  and  Execution  Process 
(DSEEP)5  and  Kweley  and  Wood6  all  assume  a  central  design  authority  and  thus  full 
control  of  the  system  of  systems  (i.e.  a  Directed  SoS  [DoD  OSD  2008])  that  result  from  the 
federation.  Within  the  CAGE  environment  “there  is  a  fundamental  requirement  to  ensure  each 
nation  retains  control  of  their  simulations,  while  federating  at  execution  time  in  a  peer-to-peer 
manner". 


1  Australia  observed  CAGE  I  and  fully  participated  in  both  CAGE  II  and  IIIA 

2  Emergent  targets  are  targets  on  the  Joint  Integrated  Prioritized  Target  List  (JIPTL)  that  cannot  be 
targeted  until  they  emerge  above  the  detection  threshold.  The  use  of  the  term  emergent  targets  was 
defined  and  agreed  across  the  CAGE  stakeholder  community  due  to  differences  in  interpretation 
for  dynamic  targets  and  time  sensitive  targets. 

3  IEEE  1516.4  April  2003  HLA  FEDEP  Standard 

4  http:/ /www,euclidlll3.com 

5  IEEE  1730-1010  Recommended  Practice  for  Distributed  Simulation  Engineering  and  Execution 
Process  (DSEEP) 

6  Engineering  Principles  of  Combat  Modeling  and  Distributed  Simulation,  Edited  by  Andreas  Tolk, 
Wiley  Press,  2012 
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The  attributes  for  a  DSDM  to  develop  a  CAGE-like  simulation  environment  are: 

•  Each  nation  has  simulation  requirements  that  are  unique  to  the  nation  and  are  not 
shared  in  the  federation. 

•  A  collegial  system  of  systems  with  decentralised  development  and  control. 

•  Experimental  objectives  drive  the  design  of  both  the  scenario  (script)  and  the 
simulation.  As  a  result  the  simulation  designers  are  not  in  control  of  the  complete  end 
system  but  are  only  responsible  for  a  portion  of  the  architecture;  the  design  must 
respond  to  requirements  which  are  driven  by  the  experiment  design  and  experiment 
execution  control  process. 

•  The  need  to  stimulate  a  selection  of  C2  systems  with  realistic  data  and  communication 
interfaces  which  are  being  designed  and  integrated  by  different  teams  through  other 
efforts. 

•  Different  requirements  for  model  fidelity  across  the  various  simulations  and  sites. 

•  Heavy  reliance  on  Government  Off  The  Shelf  (GOTS)  Software  Simulation 
environments  (Joint  Semi-Automated  Forces  (JSAF),  One  Semi-Automated  Forces 
(OneSAF),  Joint  Conflict  and  Tactical  Simulation  (JCATS)  and  commercial  products 
like  Virtual  BattleSpace  2  (VBS2). 

Constraints  on  the  DSDM  are: 

•  A  constrained  bandwidth  which  leads  to  the  requirement  for  filtering  of  information 
exchange  between  nations  and  within  national  sites;  and  the  potential  to  introduce 
novel  capabilities  such  as  the  local  construction  of  Full  Motion  Video  (FMV)  being 
created  from  other  nation  simulations. 

•  The  lowest  common  means  for  federation  across  the  nations  is  Distributed  Interactive 
Simulation  (DIS)7  and  the  High  Level  Architecture  Real-time  Platform  Reference 
Federate  Object  Model  (HLA  RPR-FOM)8. 

•  Trading  off  the  use  of  HLA  and  DIS  within  clusters  of  simulations  to  enable/ disable 
features  required  by  the  larger  federation. 

•  Capabilities  for  visualisation  of  simulation  entities  across  countries  and  simulation 
platforms  are  different  and  require  rationalisation. 

•  Differing  levels  of  knowledge  and  experience  in  distributed  simulation  design  and 
implementation. 

While  there  is  a  considerable  body  of  scientific  knowledge  on  the  principles  for  designing 
simulations,  there  is  a  gap  in  translating  these  principles  into  the  pragmatics  for  designing 
large-scale,  distributed,  peer-to-peer  federated  simulations  at  the  coalition  level  [Jessee,  S. 
etal.,  2013d], 

This  methodology  expands  upon  accepted  standards  while  integrating  simulations  into  a 
larger  decentralised  system  of  systems  design.  This  section  addresses:  the  problem 
statement,  the  aim  of  the  distributed  simulation  design  methodology,  an  overview  of  the 
methodology,  the  preliminary  design  aspects,  the  detailed  design  aspects,  the 


7  Simulation  Interoperability  Standards  Organization  (SISO)  Enumerations  for  Simulation 
Interoperability,  SISO-REF-010-2011, 19  April  2011 

8  RPR-FOM  Version  1.0  SISO-STD-OOl.  1-1999 
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implementation  aspects,  the  validation  and  verification  aspects,  and  the  assessment  of  the 
utility  of  the  methodology  in  CAGE  IIIA. 


2.  Distributed  Simulation  Methodology 


2.1  Aim  of  the  Distributed  Simulation  Design  Methodology 

The  aim  of  this  effort,  to  develop  and  trial  a  distributed  simulation  design  methodology,  is 
to  extend  the  existing  standards  approach  from  addressing  an  Acknowledged  system-of- 
systems  to  addressing  a  Directed  system-of-systems.  This  extension  is  being  achieved  by 
incorporating  appropriate  systems  of  systems  engineering  approaches  and  extending  the 
methodologies  with  systems  engineering  activities  from  the  International  Standards 
Organization  (ISO)  Standard  15288  and  by  ensuring  that  the  methodology  aligns  with  the 
experiment  design  methodology  being  developed  to  address  the  principles  of  The 
Technology  Cooperation  Program  (TTCP)  Guide  for  Understanding  and  Implementing 
Defence  Experimentation  (GUIDEx). 

The  key  challenges  for  this  methodology  are  with  understanding  how  to: 

•  design  it 

o  define  the  entities;  determine  in  which  simulation  the  entity  is  implemented 
and  determine  what  it  is  doing 

o  determine  which  entities  need  to  know  what  information  about  which  other 
entities 

o  determining  how  to  apportion  simulation  development  across  the  coalition 
o  ensuring  that  entities  implemented  across  the  coalition,  line  up  and  behave 
correctly  for  mission  threads. 

•  verify  it 

•  manage  its  design  and  development 

•  integrate  real  C2  systems  with  the  simulation  systems 

•  avoid  the  requirement  for  hard  specifications  too  early 

•  support  the  activity  streams  for  designing  an  experiment 

o  scenario  development 
o  experiment  management 
o  technical 

o  data  collection  analysis. 

2.2  Overview  of  Distributed  Simulation  Design  Methodology 

The  four  key  steps  in  the  methodology  are:  develop  a  preliminary  design;  develop  a 
detailed  design;  implement  a  solution,  and  verify  the  design  and  implementation.  For  each 
of  these  steps  we  show  the  relationship  between  the  process,  information  requirements 
and  simulation  design  products.  The  proposed  Distributed  Simulation  Design 
Methodology  expands  the  DSEEP  leveraging  ISO  15288  methods  to  account  for  the 


UNCLASSIFIED 


3 


DSTO-TN-1300 


UNCLASSIFIED 


distributed  design  aspects  by  adding  additional  control  points,  formal  verification  and 
validation  processes  and  simulation  design  products.  In  addition  the  experience  of 
conducting  the  CAGE  experiments  has  provided  lessons  and  issues  that  have  influenced 
the  methodology  design. 

2.3  Preliminary  Design 

This  section  presents  the  preliminary  design  stage  of  the  proposed  methodology.  The 
preliminary  design  enables  the  developers  to  understand: 

•  stakeholder  requirements 

•  the  entities  required 

•  the  behaviours  and  types  of  interactions  required 

•  entity  allocation  across  simulations  and  nations 

•  entity  information  exchange  requirements  across  simulation 

•  filtering  requirements 

•  data  requirements  to  support  the  simulation 

•  C2  interface  requirements 

•  requirements  for  supporting  the  experiment  objectives,  and  the  experiment  analysis 
activities 

•  Where  and  how  it  is  executed.  In  particular: 

o  Who  is  responsible  for  which  portions  of  the  overall  simulation? 
o  allocation  of  entities  and  behaviours  to  nations  and  simulations 
o  the  reporting  of  simulation  events,  actions,  etc.  to  the  C2  systems 

•  What  validation  is  required  and  how  it  is  validated.  In  particular: 

o  ensuring  the  entity  alignment  and  interactions 
o  verifying  that  the  visualisation  meets  the  experimental  goals 
o  verifying  the  sensor  interaction  with  entities 

o  the  latency  associated  with  information  flows  within  the  federation  and 
interfaces  to  the  C2  systems  is  acceptable  to  the  experiment  designers 
o  verifying  the  correlation  of  time,  space  and  behaviour  across  simulations. 

2.3.1  Overview  of  the  Preliminary  Design 

The  ability  to  execute  the  preliminary  design  is  extremely  dependent  upon  information 
being  made  available  from  other  parallel  processes  associated  with  experiment  design  and 
scenario  development.  Figure  1  shows  the  information  flows  from  the  parallel  processes 
and  the  interactions  required,  supporting  the  preliminary  design,  within  the  context  of  the 
distributed  simulation  design  methodology.  Figure  2  shows  the  process  flow  for  the 
preliminary  design  step,  mapping  the  information  requirements  and  the  simulation  design 
products  that  are  generated.  This  process  was  trialled  in  the  CAGE  IIIA  simulation  design 
activities.  The  remainder  of  Section  2.4  elaborates  each  design  step. 
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Figure  1:  Preliminary  Design  Information  Requirements 


{ 


Map  Data  requirements 


Data  Sets  requirements 


j 


~y~ 


~y~ 


j 


What  is  needed 


Behaviour  needed 


Where  it 

is  executed  Simulation  Architecture 


Figure  2:  Preliminary  Design  Process 
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2.3.2  Driving  and  Eliciting  Simulation  Design  Requirements  from  the  Scenario 
Design  Process 

The  scenario  design  methodology  applied  in  CAGE  IIIA  consisted  of  four  phases:  Scenario 
Guidelines;  Scenario  Story  board  (SSB);  Scenario  Writing  board  (SWB)  and  Scenario 
Review.  Each  phase  includes  several  activities  that  refined  the  scenario  and  increased  the 
level  of  detail.  The  output  of  these  activities  is  used  as  requirements  for  a  number  of 
internal  actions  within  the  overall  experiment  design.  In  particular  the  scenario  script  is 
used  in  the  generation  of  the  simulations. 

Figure  3:  Scenario  Design  Method  shows  the  distributed  simulation  design  methodology 
used  for  the  CAGE  experiment  campaign. 


Scenario  Guidelines  Scenario  Story  board  Scenario  Writing  board  Reviewing 


Figure  3:  Scenario  Design  Method 

The  top  half  of  Figure  3:  Scenario  Design  Method  shows  the  products  interfaces  between 
the  SWG  and  the  other  working  groups.  The  lower  half  of  the  figure  shows  the  steps  of  the 
methodology  over  the  four  phases  of  development. 


2.3.2.1  Scenario  Design  Products 

This  section  describes  the  products  that  are  created  and  then  how  the  products  inform  the 
scenario  development  process. 


Between  the  concept  design  conference  (CDC)  and  the  initial  planning  conference  (IPC) 
several  products  were  created  to  guide  the  design  of  the  experiment  including  the 
scenario.  These  products  were  agreed  upon  at  the  National  and  Coalition  levels  and 
include: 
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•  Experiment  Objectives 

•  basic  C2  nodes 

•  areas  of  responsibility  for  each  country 

•  any  national  internal  Areas  of  Responsibility  (AOR) 

•  high  level  Blue/ Red  Scheme  of  Manoeuvre  (SoM) 

•  Red  ORB  AT 

•  Blue  ORB  AT  from  each  nation 

•  an  indication  of  which  assets  are  participating  or  being  simulated. 

The  output  products  of  this  phase  include:  a  detailed  SoM,  theme  overview  sheets  with 
missions  threads  identified  and  a  rough  event  flow  chart  of  themes  and  missions. 

Figure  4:  Basic  Scenario  SoM  shows  the  basic  outline  of  a  Scheme  of  Manoeuvre  as  well  as 
indicating  the  main  objectives  or  end-states  of  each  day,  these  guidelines  indicate  the 
desired  intensity  as  the  scenario  progresses. 


Basic  Scenario  Guidelines 


Day  1 


Day  2  Day  3 


Day  4 


Figure  4:  Basic  Scenario  SoM 


The  guidelines  for  the  scenario  also  include  approximate  Areas  of  Operation  (AO)  or 
Areas  of  Responsibility  (AOR)  for  each  nation.  This  provides  the  simulations  with  the  area 
for  the  simulations  to  interact  and  allows  the  SSB  to  be  informed  of  the  ability  of  the 
simulation  terrain,  entity  and  mapping  capabilities  to  support  the  scenario.  Figure  5:  An 
example  of  a  SoM  for  a  particular  scenario  day  in  CAGE  IIIA.  It  shows  the  Red  force 
coming  in  from  the  east  with  Blue  forces  moving  out  from  the  centre.  It  also  shows  several 
skirmishes  with  red  entities  to  the  south  and  west.  This  scheme  of  manoeuvre  provides  the 
approximate  locations  of  blue  force  elements,  red  force  elements  and  civilian  traffic  for  the 
start  of  day  and  the  individual  trials  and  DMTs. 
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Figure  5:  An  example  of  a  SoM  for  a  particular  scenario  day 


Figure  6  shows  the  linkages  between  themes  in  CAGE  IIIA.  The  linkages  enable  the 
simulation  designers  to  understand  both  the  necessary  and  the  supporting  entity 
behaviours.  Entities  whose  behaviour  supports  the  identified  themes  are  necessary  but  all 
other  entities  behaviour  specified  in  the  scenario  design  are  supporting  and  therefore  of 
lower  priority  with  regard  to  ensuring  behaviour  is  correct  and  verified. 


Figure  6:  Shows  the  linkages  between  themes  in  CAGE  IIIA 
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Injects  are  the  external  stimulus  applied  to  the  experiment  participants  in  order  to  trigger 
certain  participant  behaviour.  Injects  include  exact  location,  time,  entities  involved,  and 
the  inject  source.  The  structure  of  the  inject  sheets  produced  in  the  SWB  are  driven  by  the 
needs  of  the  simulation  team  who  are  required  to  translate  the  script  into  detailed 
simulations.  The  design  of  the  inject  sheets  is  provided  below. 
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Figure  7:  The  template  for  creating  the  scenario  script 


Figure  7  shows  the  template  for  creating  the  scenario  script  with  the  column  headings  of 
the  inject  sheet  for  each  theme.  The  headings  read  from  left  to  right: 

•  Inject  ID:  a  unique  number  for  that  inject  for  that  day  (auto  assigned,  for  scenario 
control) 

•  Theme-Day-Mission:  The  mission  identifier  that  links  to  the  day  and  theme 

•  ZULU:  the  time  to  the  minute  of  when  the  inject  occurs  (for  scenario  control, 
analysts,  simulation  design). 

•  Reporting  agency:  this  is  the  simulation  entity  or  other  entity  that  is  responsible  for 
reporting  this  inject  (i.e.  a  combat  team,  forward  observer,  pilot,  Intel  source)  (For 
scenario  control,  analysts,  simulation  design) 

•  EXCON  injector:  this  is  the  role  within  EXCON  who  is  acting  on  behalf  of  the 
reporting  agency  to  make  the  inject  (For  scenario  control,  technical  team, 
simulation  team). 

•  Data  transfer  medium:  specifies  by  what  means  the  inject  is  provided  to  the 
participants.  For  example  voice,  chat,  email,  AFATDS,  TORC2H  message,  FMV, 
Link  16,  VMF,  DCTS.  (for  scenario  control,  technical  team,  simulation  team, 
analysts) 

•  Receiver:  The  participant  who  is  expected  to  receive  this  information.  (Scenario 
control,  technical  team,  analysts,  simulation  design) 

•  Trigger  Inject:  Specifies  whether  this  inject  must  be  inserted  at  exactly  this  time  or 
dependent  on  other  events  before  injecting.  (Scenario  control) 

•  Narration:  This  is  a  description  of  the  situation  and  what  needs  to  be  injected.  This 
does  not  specify  the  exact  wording  of  the  inject,  this  narration  should  be  scenario 
relevant  and  use  military  language  or  properly  formatted  messages  depending  on 
the  transfer  medium.  (Simulation  team,  scenario  team).  This  narrative  also  needs  to 
indicate  what  is  pre-scripted  and  what  is  indicative,  as  well  the  narrative  needs  to 
provide  the  expected  outcomes  versus  the  desired  outcomes 

•  Blue  sim  ID:  used  to  specify  which  blue  unit  the  inject  is  from/involves. 
(Simulation  team) 

•  Red  Sim  ID:  used  to  specify  which  red  target  is  involved/ targeted  in  this  inject. 
(Simulation  team) 

•  Mission  type:  used  to  specify  which  mission  type  this  inject  should  trigger. 
(Analysts) 

•  AS/UK/ CA:  Used  to  indicate  which  nation  is  responsible  for  inserting  this  inject  to 
the  participants.  (Scenario  Control) 
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•  Named  Location:  Used  to  specify  the  location  of  the  inject  or  entities  in  the  inject.  If 
the  location  is  well  known,  just  a  name  is  enough.  (Scenario  Control,  simulations) 

•  Issues:  Used  to  flag  possible  issues  with  the  inject.  (Scenario  Control,  tech  team, 
simulation  team,  analysts) 

Figure  8  shows  asset  tracking  across  themes  and  time  shows  an  example  of  the  blue  force 
assets  used  on  one  particular  day  of  the  CAGE  IIIA  scenario.  Asset  tracking  allows  the 
identification  of  resource  conflicts  across  mission  threads;  or  the  identification  of  resources 
that  are  not  being  used  (such  as  MRLI-4  in  Figure  8)  that  can  be  applied  to  the  mission 
threads  or  deleted  from  the  ORBAT.  This  Spreadsheet  is  reused  in  the  detailed  design  as 
the  input  for  the  entity  behaviours  as  described  in  section  2.5.2. 
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Figure  8:  Asset  tracking  across  themes  and  time 


Once  all  of  the  individual  scripts  for  each  theme  have  been  finalised  they  are  combined  to 
create  a  single  list  of  injects  in  chronological  order  for  each  day  of  the  scenario.  This  is 
where  each  theme  is  interwoven  with  all  other  themes  for  the  day. 


2.3.22  How  the  products  inform  the  Scenario  Development  Process 

At  this  point  the  single  list  of  injects  in  the  chronological  order  for  each  day  represent  the 
ground  truth  of  the  scenario  and  the  products  discussed  in  section  2.4.2. 1  are  used  to 
inform  the  following  steps  in  the  scenario  development  process. 

Identify  Entities  to  be  Modeled 

This  step  involves  assessing  the  Order  of  Battle  developed  by  the  scenario  writers  for  the 
blue  force,  red  force,  insurgents  and  non-combatants,  the  level  of  background  activity 
required  to  create  a  realistically  cluttered  environment,  etc. 

Identify  Entity  Behaviour 

Leveraging  the  scheme  of  manoeuvre  defined  in  the  scenario  the  individual  entities  are 
assessed  with  respect  to  required  manoeuvre  and  behaviours.  This  assessment  results  in  a 
set  of  characteristics  that  the  simulation  will  require  in  delivering  the  anticipated  scenario. 
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This  could  include  visualisation,  articulated  parts,  electronic  signatures,  realism  of 
movement,  etc. 

Define  Entity  to  Entity  Interactions 

In  this  task  the  interactions  between  entities  is  assessed  with  respect  to  the  scenario  and 
scheme  of  manoeuvre.  This  identifies  entities  that  will  never  interact  and  do  not  need  to 
receive  information  about  each  other.  This  will  feed  into  the  filter  design  task  later  on.  In 
addition  this  task  will  identify  visualisation  requirements  or  EW  and  IR  signature 
requirements.  It  will  identify  the  potential  for  weapon  engagements  between  entity  pairs, 
potential  for  aggregation  of  entities  for  group  behaviour,  etc.  This  analysis  will  provide 
simulation  characteristics  for  the  selection  of  simulations  and  for  the  allocation  of  entities 
to  simulations  task. 

Define  Entity  Interactions  with  C2  Systems 

Each  of  the  entities  are  assessed  to  determine  which  C2  systems  should  be  provided  data 
from  the  entity,  the  type  of  interaction,  the  Tactical  Data  Link  and  associated  messages  that 
should  be  used,  the  update  rates,  how  the  interaction  is  initiated,  how  it  continues, 
frequency  requirement,  etc. 

The  types  of  C2  interaction  can  be  a  blue  entity  self-reporting  its  location,  an  entity  being 
sensed  by  entities  (for  example  a  RADAR  site),  reporting  events  that  are  occurring  inside 
the  simulation  (significant  event  reporting),  firing  weapon  systems,  weapon  system  status, 
full  motion  video  (FMV)  feeds,  etc.  This  analysis  is  used  in  selecting  which  simulations  are 
required  in  the  federation  and  allocating  an  initial  set  of  entities  to  the  simulations. 

For  each  entity  the  appropriate  C2  identifiers  associated  with  the  entity  such  as  the  Unit 
Resource  Number  (URN),  2525B  symbol,  call  sign,  IFF  code,  etc.  are  acquired  from  the 
scenario  design  documentation,  national  registries  or  created  and  associated  with  the 
entities.  This  data  will  need  to  be  coded  into  the  entities  during  the  implementation  phase. 

Allocate  entities  to  Simulations 

In  this  step  the  information  from  the  previous  steps  are  used  to  identify  which  simulation 
environments  will  be  federated  in  each  country  and  which  entities  will  be  modeled  in  each 
of  these  simulations.  The  entity  to  simulation  allocation  will  as  a  minimum  be  a  function  of 
geographic  coverage,  C2  interface  capabilities,  entity  interactions,  computational  load,  and 
model  characteristics. 

Define  Enumeration  values 

Using  the  list  of  entities  for  each  simulation,  their  nationalities  (birth  or  manufacturing), 
etc.  the  most  appropriate  enumeration  is  identified  for  the  entity.  Once  this  has  been  done 
then  a  mapping  of  the  entity  enumeration  for  each  type  of  simulation  in  the  federation  is 
compiled.  Where  holes  exist  in  this  mapping  (i.e.  a  simulation  does  not  have  the 
appropriate  model  then  the  best  fit  model  is  identified  and  mapped  to  the  entity.  This  list 
is  used  to  create  the  HLA/DIS  gateways  and  to  map  entities  within  simulations. 
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Identify  Information  Exchange  Requirements  Between  Simulations 

In  this  step  identify  an  initial  information  exchange  requirement  from  simulation  to 
simulation  and  from  site  to  site.  This  understanding  is  intended  to  identify  simulations 
that  do  not  have  to  interact  (for  example  a  UAV  simulator  may  not  need  to  interact  with  an 
EW  simulator).  As  well,  simulators  that  have  a  large  geographic  separation  between 
entities  and  no  way  to  sense  each  other's  entities  may  not  have  to  interface. 

Define  Gateway  Interfaces  and  Networking  Requirements 

In  this  step  the  task  is  to  identify  the  requirement  to  have  Gateways,  and  filters  between 
simulators  and  sites.  Gateways  that  may  be  required  will  interface: 

•  HLA  simulations  with  the  DIS  backbone 

•  simulations  to  C2  systems 

•  site  to  site 

•  nation  to  nation. 

In  addition  as  this  assessment  is  performed  and  the  Gateways  identified  the  characteristics 
of  the  long-haul  network  between  sites  in  the  federation  may  require  the  Gateways  to 
convert  the  network  transmission  from  broadcast  to  multicast  and  back,  change  IP  and 
ports  used,  block  entity  or  PDU  type  transmissions. 

Ensure  Data  Collection  Plan  requirements  are  Designed  into  the  System 

Leveraging  the  developing  data  collection  plan  and  the  EXCON  requirements  identify  the 
requirement  for  data  loggers,  "god's  eye  view'  tools,  etc.  within  the  simulation 
architecture.  Identify  the  requirement  for  interactors  and  to  provide  EXCON  with  access  to 
portions  or  all  the  simulation.  Define  the  interaction  between  the  simulation  federation 
and  the  execution  of  the  experiment. 

Develop  an  Overarching  Architecture  of  the  Simulations 

The  preceding  tasks  provide  the  material  necessary  to  develop  a  high  level  architecture  of 
the  simulations  in  the  federations  and  their  interaction  with  other  systems  and  users. 

Simulation  Preliminary  Design  Review 

Exiting  this  Stage  of  the  design  occurs  through  the  successful  execution  of  a  Preliminary 
Design  Review  (PDR).  This  review  assesses  the  outputs  of  each  step  using  a  walk-through 
of  the  Federation  Agreement  Document  and  the  Entity  Identification  Spreadsheet  which 
are  used  to  record  the  data  products  of  these  steps.  This  step  should  align  with  the  Main 
Planning  Conference. 

2.3.3  Distributed  Simulation  Design  Products 

The  following  section  presents  examples  of  the  data  products  that  are  developed  during 
the  preliminary  design  process.  The  Data  products  are: 

•  Entity  Definition  Spread  Sheet 

•  Federation  Agreement 

•  Architecture  Diagrams. 
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2.3. 3.1  Entity  Definition  Spread  Sheet 

A  key  repository  of  information  developed,  in  the  various  steps  in  the  preliminary  design, 
is  the  Entity  Definition  Spread  Sheet.  This  spreadsheet  has  several  tabs  used  to  collect  and 
correlate  the  different  information.  The  tabs  are: 

•  Blue  Nations  Land  DIS  List 

•  Blue  Nations  AIR  DIS  List 

•  Blue  Nations  Maritime  DIS  List 

•  Red  List 

•  Green  Entity  DIS  List 

•  Green  ORB  AT 

•  Munitions  List 

•  URN  Look  up  Table  &  C2  Interfaces. 

Depending  on  the  design  some  or  all  of  these  tabs  would  be  used  and  it  is  possible  that 
additional  tabs  would  be  required.  These  tabs  are  described  below  with  an  example  of  the 
type  of  data  that  was  captured  during  CAGE  IIIA. 

Blue  Nations  Land  DIS  List 

This  tab  of  the  spreadsheet  records  the  Blue  Land  Order  of  Battle  (ORBAT)  and  applicable 
information  about  the  entities.  This  data  is  compiled  from  an  assessment  of  the  scenario 
information  and  then  augmented  through  an  understanding  of  the  requirements  for 
associated  command  structures  to  enable  the  simulations  to  link  the  entities  into  units. 


Entity  Shoit  Home  (ijieen  Font  lifefoim) 

DIS  ENU 

ShoitName 

Notes 

Symbol 

ADA  ADAGenericLauncher  4  Enaaoement  Control  Station 

1.1 .225.28  2.2.1 

CRAM 

S  F  G’EWMA--***** 

ADA  Radar  Giraffe 

9.1.205.2.5.1.0 

Giraffe 

SFG’UUMRG-***** 

Figure  9:  Template  spreadsheet  to  record  blue  land  entities 

Blue  Nations  AIR  DIS  List 

This  tab  of  the  spreadsheet  records  the  Blue  Air  Order  of  Battle  (ORBAT)  and  applicable 
information  about  the  entities.  This  data  is  initiated  by  an  assessment  of  the  scenario 
information  and  then  augmented  through  an  understanding  of  the  requirements  for 
associated  command  structures  to  enable  the  simulations  to  link  the  entities  into  units. 


Aii  Unit 

Number  of 

Units 

Type 

Component  Units  Entities 

ENU 

URN 

Equipment 

DIS-ENU 

Attachment 

DIS-ENU 

ARH-SQN 

6 

Entity 

ARH1 

1.2.13.20.1.1.0 

ARH2 

1.2.13.20.1.1.0 

Figure  10:  Template  spreadsheet  to  record  blue  air  entities 


Blue  Nations  Maritime  DIS  List 

This  tab  of  the  spreadsheet  records  the  Blue  Maritime  Order  of  Battle  (ORBAT)  and 
applicable  information  about  the  entities.  This  data  is  initiated  by  an  assessment  of  the 
scenario  information  and  then  augmented  through  an  understanding  of  the  requirements 
for  associated  command  structures  to  enable  the  simulations  to  link  the  entities  into  units. 
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Attachment  DiS-ENU 


8_CAQBII_ARO_MARITIME  LHO 


CanOerra  A  8_M  ARTIME_LHD_uarKMna_HoMooote  r_Do 
Adelaide  A  8_M  ARTIME_LHO_Landlno_Hel  looote  r_Do 

Hooert  A  a_M  ARTIME_AWO_Alr_Worfam  _De«royer 

sn scene  A  8JJ  ARTIHE_AWD_Alr_WarTaieJDestroyer 

Anzeo  AS_MARTIME_FFH_ANZJIC 

Arunta  A  8_M  A  RTIME_FFH_A  RZ»  C 

Sydney  A  8_MARTIME_FFO 

Oarwm  AS  _MARTIME_FFO 

Choules  A8_MARTIME_Cnoules 

8H80  A8_MARTIME_8HaOR 

A8_MARTIME_8H40R 
A  8  JA  A  RTI M 8 H80  R 
A8_MARTIHE_8l+aOR 
A8_MARTIME_8H80R 
A8_MARTIME_8l+aOR 
A  8_MARTIME_BH-SaR 
UAV  A  841  A  RTIME_UA  V 


1.3.13.54.1.1.0  XXXX186  One  SAP 

1.3.13.54,1.1.0  J8AF 

1.3.13.4.1.1.0  J8AF 

1.3.13.412.0  J8AF 

1.3.13.62.1.0  XXXX188  OneSAF 

1.3.13.622.0  XXXX187  OneSAF 

1.3.13.6.1.1.0  J8AF 

1.3.13.6.12.0  J84F 

1.3.13.16.21.0  J8AF 

1.213.2221.0  J8AF 

1.213.2221.0  J8AF 

1.213.2221.0  J8AF 

1.213.2221.0  J8AF 

1.213.2221.0  J8AF 

1.213.2221.0  J«AF 

1.213.2221.0  J8AF 

1.2225.50.8.10  XXXXQ28  piMS 


Figure  11:  Template  spreadsheet  to  record  blue  maritime  entities 


Red  List 

This  tab  of  the  spread  sheet  records  the  RED  Order  of  Battle  (ORBAT)  and  applicable 
information  about  the  entities.  This  data  is  initiated  by  an  assessment  of  the  scenario 
information  and  then  augmented  through  an  understanding  of  the  requirements  for 
associated  command  structures  to  enable  the  simulations  to  link  the  entities  into  units. 


Short  Name 

Side 

DIS#:Puntland-300, 

Alshebaab-195 

SIM 

Allocation 

60mm_Motor_Gunner 

PUNTLAND 

3.1.300.1.228.103 

OneSAF 

BTR-70-Generic 

PUNTLAND 

1.1.222.2.12.1.0 

OneSAF 

BTR-70BREM-Repair 

PUNTLAND 

1.1.222.2.12.8.0 

OneSAF 

BTR-70KshM-Command 

PUNTLAND 

1.1.222.2.12.7.0 

OneSAF 

BTR-70MS-Comms 

PUNTLAND 

1.1.222.2.12.6.0 

OneSAF 

BTR-70SPR-2- Jammer 

PUNTLAND 

1.1.222.2.12.5.0 

OneSAF 

D30  -  HOW 

PUNTLAND 

1.1.222.5.4.0.0 

OneSAF 

Figure  12:  Template  spreadsheet  to  record  red  entities 


Green  Entity  DIS  List 

This  tab  of  the  spread  sheet  records  the  non-combatant  (Green)  Order  of  Battle  (ORBAT) 
and  applicable  information  about  the  entities.  This  data  is  initiated  by  an  assessment  of  the 
scenario  information. 


Entity  Type 

Nationality 

Number  of 
entityies 

Type 

Component  Units  Entities 

ENU 

URN 

Equipment 

DIS-ENU 

Attachment 

DIS-ENU 

Container  Ship 

Count  ryl 

300 

Entity 

CTSHIP1 

1.3.222.61.1.0 

CTSHIP2 

1.3.222.61.1.0 

Figure  13:  Template  spreadsheet  to  record  green  entities 


Munitions  List 

This  tab  of  the  spread  sheet  records  the  munitions  to  be  deployed  during  the  simulation. 
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Ammunitions 

DIS  Enumeiation 

projectileFAl  05mmDPICMM916 

2.9.225.2.10.20.0 

missileSCUDNuke3Kt 

2.11.222.2.2.6.0 

projectileFAl  55mmFleM1Denel 

2.9.197.2.1 .1 .0 

Figure  14:  Template  spreadsheet  to  record  munitions 


URN  Look  up  Table  and  C2  Interfaces 

This  tab  of  the  spread  sheet  records  the  C2  interfaces  and  applicable  information  required 
for  the  interface  to  work  by  entities. 


URN 

Unit  Short  Name 

Unit  Long  Name 

Nation 

Service  1 

Symbol 

DIS  marking 

c2  interface 

5811717 

SF  PL/FT3/ 

SF  PL/FT3/ 

AS 

A 

SFGPEWRR--***** 

ASA-5811717 

TMS-2 

5811711 

SF_PL/FT2/ 

SF_PL/FT2/ 

AS 

A 

SFGPEWRR--***** 

ASA-5811711 

TMS-2 

Figure  15:  Template  spreadsheet  to  record  the  C2  interface  information  for  entities 


2.33.2  Federation  Agreement 

The  second  distributed  simulation  design  product  is  the  Federation  Agreement.  It 
provides  a  repository  for  the  descriptive  data  developed  and  compiled  during  the 
preliminary  design  as  well  as  agreements  between  the  sites  and  nations.  The  following 
table  of  contents  provides  an  example  of  the  topics  covered  in  this  document  for  the  CAGE 
IIIA  simulation. 


Distributed  Federation  Simulation  Agreement 
Table  of  Contents 

1.  PURPOSE 

2.  DOCUMENT  VERSIONS  AND  UPDATES 

3.  REFERENCES 

4.  EXPERIMENT  OVERVIEW 

4.1  General 

4.2  Scenario  Location 

4.3  Scenario 

5.  SIMULATION  INFRASTRUCTURE 

5.1  Overall  Network  Environment 

5.2  Australia  Simulation  Environment  Overview 

5.3  Canada  Simulation  Environment  Overview 

5.4  UK  Simulation  Environment  Overview 

5.6  RTI 

5.7  DIS 

5.8  FOM 

6.  RTI  SERVICES 

7.  SIMULATION  MANAGEMENT 

8.  TIME  OF  EVENTS 

9.  OPTIONAL  ATTRIBUTES  AND  PARAMETERS 

10.  UPDATES  AND  QUERIES 

11.  IDENTIFIERS 

11.1  Internal  Federation  Name 

11.2  RTI  and  Application  ID 

11.3  Site  ID 

12.  COORDINATE  SYSTEMS 
12.1  JSAF  Terrain  (ALL) 
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12.2  VBS2  Terrain  (ALL) 

12.3  CAMX  (Canada) 

13.  KINEMATIC  ATTRIBUTES 

14.  DEAD  RECKONING 

15.  UPDATE  THRESHOLDS 

16.  ENTITY  COORDINATES 

17.  GROUND  CLAMPING 

18.  USER  DEFINED  TAGS 

19.  DATATYPE  REPRESENTATION 

20.  ENDIANESS 

21.  ALIGNMENT  AND  PADDING 

22.  TRANSPORT  MECHANISMS 

23.  TIMEOUTS 

24.  ENTITY  REPRESENTATIONS 

25.  COMBAT  INTERACTIONS 

26.  ENTITY  ENUMERATIONS 

27.  AGGREGATE  ENUMERATIONS 

28.  COUNTERMEASURES 

28.1  Concealment 

28.2  Decoys  -  Chaff 

29.  OBJECTS  AND  INTERACTIONS 

30.  VV&A 

31.  OPERATIONAL  SCENARIO 


2.3. 3.3  Architecture  Diagrams 

The  third  distributed  simulation  design  product  developed  in  the  Preliminary  Design 
phase  is  the  initial  System  View  of  the  federation  and  its  interfaces.  The  following  diagram 
shows  the  federated  systems  view  for  the  CAGE  IIIA  experiment. 


Federation 


UnM  Kingdom 


UK 


r  M 

_ 1 _ , _ _ . _ _ _ , _  (MMwih* 

. .  —  NMkk  Nftoxk 


Figure  16:  Preliminary  Federation  System  View 
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2.4  Detailed  Design  Phase 

The  detailed  design  enables  the  developer  to: 

•  identify  the  script-ability  of  experiment  threads  verse  requirement  for  interactor  to 
implement  entity  behaviour  and  actions  in  real  time  to  respond  to  events 

•  determine  the  entity  aggregation  and  de-aggregation  requirements 

•  develop  the  detailed  C2  interfaces 

•  identify  the  data  collection  points  and  ensure  the  data  will  be  recordable 

•  identify  experiment  control  points  for  managing  the  execution  of  the  simulation  and 
varying  the  tempo  if  required 

•  further  development  the  details  of  the  architecture 

•  determine  the  verification  requirements  for  the  behavioural  allocation  across  the 
architecture. 

The  following  diagram  demonstrates  the  interaction  between  the  various  design  processes 
and  this  stage  of  the  simulation  design.  Information  from  the  preliminary  design  stage  as 
well  as  information  from  the  scenario  design  and  the  experiment  design  is  used  in  this 
stage.  The  results  of  the  work  performed  can  have  significant  impact  in  the  details  of  the 
scenario  and  the  implementation  of  the  experiment  plan  as  shown  in  the  centre  and  right 
hand  parts  of  the  figure. 


Entity  Definition  Spread 
Sheet 


Entities 

Initial  allocation  to 
simulations 
C2  Interfaces 


Scheme  of  Manoeuver 
Textual  script  by  theme  and  mission 
Indicative  or  expected  responses  from 
target  audience 


Experiment  Design 


Minimizing  information  flow 
between  simulation 
Improvement  of  the  initial 
architecture 
Identification  of 
requirements  to  support 
interactors 

Update  to  Federation 
Agreement  and  Architecture 
diagrams 


Script  deconfliction 

Verification  that  entities  can  execute  the 
scripts 

Missing  entities 

Alternatives  for  collecting  data 

Initial  set  up  required  in  the  simulations  by 

theme  and  mission 


Scenario  Design 
Experiment  Design 


Themes  and  Mission  Threads 
Data  Points 

Data  collection  requirements 


Assessment  of  themes  and  mission  script 
to  identify:  ^ 

•  Definition  of  automation  scripts 

•  Definition  of  Human  interactor  roles 

•  Verification  of  assigned  entities 


Figure  17:  Detailed  design  information  flow 


2.4.1  Detailed  Design  Process 

This  section  describes  each  step  of  the  detailed  design  process  shown  in  Figure  18 
mapping  the  information  requirements  and  the  simulation  design  products  that  are 
generated. 
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Figure  18:  Detailed  design  process  steps 

Scenario  Deconfliction 

In  this  step  the  scenario  description  provided  by  the  scenario  writing  board  is  deconflicted 
in  time  and  space.  The  intent  is  to  ensure  that  the  script  envisioned  can  execute  in  the  time 
frames  required,  that  there  are  sufficient  entities  in  the  Order  of  Battle,  and  the  modelled 
characteristics  and  real  life  behaviour  can  achieve  the  desired  outcomes  of  the  script. 
Conflicts  identified  are  provided  to  the  experiment  design  and  scenario  writers  to  redress. 
This  task  repeats  until  a  deconflicted  scenario  is  achieved.  The  results  of  this  activity  are 
recorded  in  the  Script  Entity  Behaviour  Spread  Sheet  [see  section  2.5.2], 

This  step  informs  the  scenario  development  board  and  the  experiment  design  of  conflicts 
in  the  scenario  script  including: 

1.  location  discrepancies 

2.  gaps  in  capability 

3.  timing  issues. 

In  an  iterative  process  these  discrepancies  are  removed  through  clarification  of  intent  for 
the  theme/ mission,  adjustments  to  theme  and  mission  timings,  adding  entities  to  the 
ORBATS,  and  either  rewriting  of  scripts  or  accepting  the  conflicts  as  being  required 
features  to  test  the  experimental  objectives. 

This  step  ends  when  there  is  a  script  that  can  be  executed  in  a  fashion  that  will  achieve  the 
experimental  play  expected.  This  deconfliction  only  assures  that  for  a  single  path  and  with 
the  anticipated  player  decisions  there  are  sufficient  entities,  tasking,  and  time  and  space 
coordination  to  achieve  the  anticipated  outcomes.  It  does  not  ensure  that  every  execution 
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path  can  be  performed;  nor  that  their  mission  objectives  can  be  achieved  if  different 
choices  are  made  during  the  scenario  play. 

Theme  Analysis 

In  this  step  the  Script  Entity  Behaviour  Spread  Sheet  [see  section  2.5.2.]  is  assessed  with 
respect  to  the  individual  experimental  themes  and  missions.  The  deconflicted  scripts  are 
separated  into  the  individual  themes  that  are  intended  to  deliver  the  desired  experimental 
data  points  to  be  used  by  the  analysts.  Each  theme  is  then  assessed  to  ensure  that  the  intent 
of  the  theme  can  be  achieved.  The  experimental  data  points  are  identified  along  with 
critical  set  up  conditions  that  are  required  for  the  data  point  to  achieve  a  useful  result. 

The  results  of  this  activity  include  identifying  the  following: 

•  Potential  for  entity  aggregation  and  de-aggregation  during  the  theme. 

•  Define  the  DIS  Enumeration  of  the  aggregated  entity  representing  the  individuals 
when  aggregated. 

•  Identification  of  the  data  collection  points  within  the  individual  themes  and  associated 
missions. 

•  Entity  initial  conditions  required  to  achieve  the  desired  theme  outcomes 

•  Alternative  opportunities  to  achieve  the  desired  set  of  data  points  associated  with  the 
theme  and  missions. 

•  Entities  central  to  experimental  goals  and  those  providing  background  noise,  extra 
work  and  ones  that  could  be  scripted  without  impact  of  time  and  space  adjustments  to 
the  theme  and  missions.  For  example  shipping  traffic  through  which  the  entity  moves 
while  being  tracked  and  ultimately  engaged  could  be  scripted  to  have  a  defined 
behaviour. 

Entity  Behaviour  Analysis 

For  each  theme  and  mission  the  entities  are  assessed  with  respect  to  the  ability  of  the 
model  in  the  selected  simulation  to  provide  the  necessary  behaviours,  the  entity 
interactions  and  the  ability  to  publish  required  information  and  created  the  desired  effect 
on  other  entities.  In  addition  the  requirement  for  interactor  control  of  the  entity  verse 
scripted  control  of  the  entity  is  assessed.  The  result  of  this  analysis  is  an  understanding  of 
the  entity  behaviours  that  can  and  should  be  scripted  and  which  behaviour  needs  to  be 
initiated  and  directed  by  an  interactor.  For  example  if  a  group  of  entities  need  to  go  from 
point  a  to  point  b  in  order  to  be  in  a  location  that  enables  an  event  in  the  mission  or  theme 
a  time  initiated  script  may  work.  In  another  case  a  series  of  actions  may  occur  for  a  single 
or  group  of  entities,  depending  on  the  outcome  of  actions  taken  by  the  target  audience. 
This  analysis  may  result  in  several  scripts  being  created  that  can  be  initiated  if  and  when 
required  or  it  may  need  the  interactors  to  react  appropriate  to  the  response.  The  following 
diagram  demonstrates  how  the  theme  and  its  associated  missions  are  examined  with 
respect  to  the  entities  assigned  and  the  time  activities  with  the  intent  of  determining  how 
time  and  position  independent  of  the  various  themes  and  missions  can  be  made. 
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Interface  with  other  systems 
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En 


Figure  19:  Assessment  by  theme  for  time  and  space  independence 

Where  command  and  control  interaction  is  required  of  the  entity  this  relationship  is 
identified  and  defined.  For  example  if  a  gun  battery  in  the  simulation  is  to  be  fired  by  a 
command  and  control  system  the  command  relationship  that  enables  the  simulation  to 
execute  this  is  defined  as  well  as  the  interface  behaviour  (messaging)  required  by  the  C2 
system. 


The  types  of  issues  that  might  be  identified  through  this  step  include: 

•  No  munition  in  the  simulations  with  the  flight  characteristics  to  achieve  the  anticipated 
goal  during  the  scenario  being  modelled. 

•  Intended  information  exchange  with  the  C2  system  specified  will  not  work  as  there  is  a 
problem  with  the  capabilities  of  the  simulation  or  the  C2  system  with  respect  to  the 
intended  exchange  (a  message  type  has  not  been  implemented,  a  data  value  for  a  field 
of  data  required  for  the  message  does  not  exist,  etc.) 

•  Requirement  for  EXCON  staff  to  interact  with  the  simulation  to  achieve  the  requested 
free  play  behaviours. 

•  Undesirable  effects  of  entity  re-tasking  across  mission  and  themes. 


Entity  Simulator  Allocation  Re-Assessment 

Section  2.4.2.1  defined  an  initial  entity  to  simulation  allocation  in  the  preliminary  design 
stage.  The  entity  to  simulation  allocation  is  reassessed  at  the  conclusion  of  the  detailed 
design  of  the  entity  scripts  and  entity  behaviour. 


Filter  Requirements 

Fundamental  to  the  constrained  nature  of  the  communications  between  nations  and  the 
requirement  to  separate  national  and  coalition  scenario  activities  is  a  requirement  to 
implement  filters  between  the  national  simulation  federation  and  the  coalition  federation. 
The  mission  and  themes  are  analysed  to  identify  information  flow  between  simulations 
that  are  critical  to  the  execution  of  the  distributed  simulation.  Augmenting  the  efforts 
made  in  the  preliminary  design  the  following  types  of  analysis  are  made:  if  only  one 
nation  is  using  a  type  of  information  (e.g.  EW  emissions)  from  entities  then  the  other 
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nations  do  not  require  this  information  in  their  simulations  and  it  can  be  filtered  from  the 
site  to  site  communications;  if  the  information  about  emissions  can  be  retained  local  to  a 
site  then  a  filter  could  reside  at  the  site;  if  emissions  are  required  in  multiple  but  not  all 
sites  then  a  filter  could  occur  on  a  site-by-site  bases. 

The  outcome  of  this  assessment  should  identify  where  filters  are  required,  the  information 
being  filtered  by  each,  the  reason/ justification  for  the  filtering  of  the  information,  the 
impact  of  not  filtering  the  data,  and  the  conditions  that  can  be  used  to  drive  the  filter. 

The  following  diagrams  demonstrate  the  various  considerations  when  setting  up  the 
filtering  criteria  between  simulations  and  between  sites.  In  the  first  diagram  the  entity 
interaction  is  examined  in  the  context  of  the  potential  that  entities  would  sense  each  other 
or  would  move  about  each  other.  In  the  second  diagram  the  entities  are  examined  with 
respect  to  influence  between  entities  as  they  support  themes.  For  example  if  one 
simulation  is  leveraging  EW  emissions  and  another  is  not  then  their  entities  could  be  in  the 
same  time  and  space  and  have  no  influence  across  simulations  enabling  the  filtering. 


Filterable 


Not  Filterable 


Figure  20:  Using  entity  sense  and  movement  footprints  to  determine  if  filtering  can  occur 
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Filterable 


Not  Filterable 


Figure  21:  Using  Entity  influence  to  determine  if  filtering  can  occur 

Filter  Design 

In  this  stage  the  applicable  filter  tool  (e.g.  the  Canadian  tool  Bender)  is  designed  to  address 
the  filter  requirements  identified  earlier.  For  each  identified  filter  in  the  architecture  there 
is  a  list  of  entities  or  portions  of  the  information  being  shared  about  entities,  the  filter  tool 
being  used  and  how  the  entity  information  is  used  to  implement  the  filter  in  the  tool. 

Test  Plan 

In  this  step  the  plan  for  testing  the  simulation  federation  and  the  simulations  ability  to 
support  the  scenario  created  and  the  experimental  objectives  is  written.  This  plan  should 
identify  the  methods  to  be  used  for  testing,  the  schedule  and  scope  of  testing,  the 
objectives  for  the  testing  and  the  anticipated  results. 

Critical  Design  Review 

Completing  this  phase  of  the  design  occurs  through  the  successful  execution  of  a  Critical 
Design  Review  (CDR).  The  CDR  assesses  the  outputs  of  each  step  of  the  detailed  design 
through  a  walkthrough  of  the  Final  Federation  Agreement  Document,  the  Entity 
Identification  Spreadsheet,  the  Script  Entity  Behaviour  Spread  Sheet  and  simulation  design 
document  as  described  in  Section  2.5.2.  This  step  should  occur  after  the  Mid  Planning 
Conference  and  before  implementation  of  the  simulations  begins. 
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2.4.2  Distributed  Simulation  Detailed  Design  Products 

The  Detailed  Design  stage  updates  and  augments  the  following  products: 

•  Distributed  Simulation  Federation  Agreement 

•  Entity  Definition  Spread  Sheet 

•  Systems  Architecture. 

The  following  products  are  created  during  this  stage: 

•  Script  Entity  Behaviour  Spread  Sheet 

•  Detailed  Design  Document 

•  Test  Plan. 

The  following  sections  present  examples  of  the  two  data  products  that  are  developed 
during  the  detailed  design  process. 

Script  Entity  Behaviour  Spread  Sheet 

The  Asset  Tracking  Spread  sheet  shown  in  Section  2.4.2.1  Figure  8,  the  scenario  description 
and  the  DIS  enumeration  list  are  used  to  develop  an  entity  behaviour  spreadsheet.  The 
state  change  column  refers  to  the  point  in  time  when  a  mission  theme  begins.  Start 
position  refers  to  the  location  is  at  when  the  state  change  occurs.  Movement  is  a 
description  of  the  movements  and  behaviours  anticipated  for  the  entity.  The  action  is  a 
description  of  what  is  expected  to  occur  with  respect  to  the  entity. 


Table  1:  Entity  Behaviour  spreadsheet 


Mission  Threads 

Entities 

State  Change 

1 

State  Change 

2 

State  Change 

3 

State  Change 

4 

Mission  Thread  1 

Entity  1 

Start  Position; 

Movement; 

action 

Start  Position; 

Movement; 

action 

Start  Position; 

Movement; 

action 

Start  Position; 

Movement; 

action 

Entity  2 

Start  Position; 
Movement; 

action 

Start  Position; 
Movement; 

action 

Start  Position; 
Movement; 

action 

Start  Position; 
Movement; 

action 

Entity  3 

Start  Position; 

Movement; 

action 

Start  Position; 

Movement; 

action 

Start  Position; 

Movement; 

action 

Start  Position; 

Movement; 

action 

Entity  4 

Start  Position; 

Movement; 

action 

Start  Position; 

Movement; 

action 

Start  Position; 

Movement; 

action 

Start  Position; 

Movement; 

action 

Mission  Thread  1 

Entity  5 

Start  Position; 

Movement; 

action 

Start  Position; 

Movement; 

action 

Start  Position; 

Movement; 

action 

Start  Position; 

Movement; 

action 

Entity  6 

Start  Position; 

Movement; 

action 

Start  Position; 

Movement; 

action 

Start  Position; 

Movement; 

action 

Start  Position; 

Movement; 

action 
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Mission  Threads 

Entities 

State  Change 

1 

State  Change 

2 

State  Change 

3 

State  Change 

4 

Entity  7 

Start  Position; 

Movement; 

action 

Start  Position; 

Movement; 

action 

Start  Position; 

Movement; 

action 

Start  Position; 

Movement; 

action 

Detailed  Design  Document 

The  following  table  of  contents  provides  an  example  of  the  topics  covered  in  the  Detailed 
Design  Document.  This  document  provides  a  repository  for  the  description  of  the  scripts, 
filters  and  changes  to  the  simulations  required  to  implement  the  scenario.  In  addition  this 
document  records  issues  identified  during  the  design  that  will  impact  the  experiment 
design  or  scenario  execution.  This  document  covers  the  design  created  to  allow  the 
interactors  to  interface  with  appropriate  entities  to  achieve  the  desired  effects.  The 
following  is  an  indicative  Table  of  Contents: 


Detailed  Design  Document 
Table  Of  Content 

1.  PURPOSE 

2.  DOCUMENT  VERSIONS  AND  UPDATES 

3.  REFERENCES 

4.  EXPERIMENT  OVERVIEW 

4.1  General 

4.2  Scenario  Location 

4.3  Scenario 

5.  SIMULATION  INFRASTRUCTURE 

5.1  Overall  Network  Environment 

5.2  Australia  Simulation  Environment  Overview 

5.3  Canada  Simulation  Environment  Overview 

5.4  UK  Simulation  Environment  Overview 
6.0  Script  Analysis 

7.0  Theme  by  Theme  Script  Design 

7.1  Automated  Entity  Behaviour  -  across  time  and  space 

7.2  Interactor  interfaces  and  expectations 

7.3  Allocation  of  Entity  to  Simulations 

7.4  Changes  to  Simulators 

7.5  Maps,  Visualization  and  other  Data  Sets 
8.0  Filter  Requirements  &  Design 

9.0  Simulation  Management 

10.0  Recovery 

11.0  Start  states 

12.0  Implementation  management 

12.0  Verification  and  Validation  Requirements 


2.5  Implementation 

The  following  diagram  presents  the  implementation  activities  and  the  linkages  to  the 
verification  activities. 
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Figure  22:  Implementation  activities  (shown  in  green )  and  the  linkages  to  the  Verification 
Activities  (shown  in  yellow) 

Entity  Creation 

In  this  step  the  detailed  design  is  implemented  in  the  simulation  entities.  The  entity 
enumerations,  organisational  relationships,  URNs,  organisation  names,  IFF  codes,  range 
and  bearing  of  detection,  etc.  are  coded  for  every  entity  in  all  simulations.  The  result  of  this 
step  is  a  complete  set  of  entities  in  all  simulations  that  have  all  the  appropriate 
characteristics  required  to  support  the  scenario  and  the  experiment.  This  set  of  models  can 
then  support  the  entity  verification  activity  defined  in  the  Verification  and  Validation 
stage. 

Entity  Scripting 

The  scripts  defined  for  each  entity,  in  the  earlier  step,  are  coded  in  the  various  simulations. 
As  part  of  the  implementation  the  individual  behaviour  of  the  entities  in  executing  the 
script  is  tested  to  verify  it  behaves  as  specified  in  the  design  documentation. 


Filter  Creation 

The  filter  design  is  implemented  in  each  of  the  identified  filters.  The  filters  are  tested 
against  the  identified  information  flows. 
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Simulation  Federation 

The  individual  simulations  are  federated  as  a  national  federation  tested.  The  National 
federations  are  then  federated  into  a  coalition  federation. 

2.5.1  Distributed  Simulation  Implementation  Products 

The  principal  result  of  this  stage  of  the  development  methodology  is  to  have  a  working 
Federation;  working  simulation  scripts;  working  entity  Behaviour  and  interactions; 
working  Interfaces;  working  filters;  working  tools  to  support  the  scenario  Interactor;  and 
finally  all  developed  code  should  have  inline  documentation  describing  the  mapping  of 
the  code  to  the  design  and  any  special  coding  performed  to  make  the  system  work. 

2.6  Verification  and  Validation 

The  following  diagram  presents  the  verification  and  validation  activities  (shown  in 
Yellow)  as  well  as  their  interaction  with  the  implementation  process. 


Figure  23:  Verification  and  Validation  Activities  (shown  in  yellow) 

Build  Entity  Testing  Scenario 

In  this  step  a  simulation  scenario  is  created  for  each  simulation  that  has  all  of  the  entities 
that  will  be  used  in  the  simulation.  This  scenario  is  designed  and  constructed  to  allow  the 
verification  that  the  other  simulations  see  the  entities  correctly,  that  their  behaviour  is 
correct,  that  they  are  not  generating  information  that  affects  the  other  simulations  entities 
(i.e.  PDU's  of  death  (PDUs  that  result  in  a  Simulation  crashing  or  an  entity  to  die 
unexpectedly),  or  AI  behaviour  that  will  affect  the  simulation  if  not  over  ridden). 
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Verify  and  Update  Enumerations 

Leveraging  the  test  scenario  and  beginning  with  a  site  simulation  federation,  progressing 
to  a  national  and  ultimately  a  coalition  federation  verify  for  each  simulation  that  it 
properly  displays  all  the  entities  from  the  other  simulations,  has  compatible  performance 
models  for  the  entity,  does  not  have  problems  from  information  being  received  from  a 
simulation,  etc.  The  outcome  is  to  verify  that  the  model  to  model  behaviour  required  by 
the  scenario  can  properly  execute  and  deliver  the  desired  behaviour  across  the  federation. 
In  executing  this  activity  the  selected  models  for  every  entity  will  be  validated  and  any 
necessary  changes  made.  This  test  will  also  verify  that  entity  interactions  such  as  shooting 
at  each  other  works  as  expected  and  that  the  results  are  properly  represented  in  all 
appropriate  simulations. 

Verify  and  Update  Visualisation 

In  this  step  the  scenario  for  testing  will  be  leverage  to  ensure  that  the  mapping  of  a  model 
to  its  visualisation  and  other  characteristics  is  correct  across  the  simulations.  The  outcome 
of  this  test  will  be  an  agreement  that  the  visual  models,  EW  models  etc.  being  used  in  all 
the  simulators  are  the  same  or  close  enough  for  the  purposes  of  the  event. 

Verify  and  Adjust  Map  Alignment  across  Federation 

In  this  step  the  test  scenario  is  used  to  ensure  that  the  maps  being  used  across  the 
simulation  federation  are  properly  aligned,  and  have  sufficient  detail  to  constrain  entity 
behaviour  appropriately  and  are  same  across  simulations.  This  test  is  verifying  that  an 
entity  on  the  surface  in  one  simulation  is  not  underground  or  flying  in  another  simulation. 
It  is  verifying  that  an  entity  in  one  simulation  is  in  the  same  location  in  all  other 
simulations.  It  verifies  that  the  elevations  and  blockage  of  physical  structures  are  properly 
handled  by  all  entities  requiring  this  behaviour.  The  outcome  is  a  verification  that  the 
entities  properly  interact  with  the  maps  in  all  simulations  and  that  the  simulations  all 
properly  understand  the  world  the  same  (or  close  enough  to  achieve  the  desired  results). 

Verify  Script  Behaviour 

In  this  step  the  script  behaviour  is  verified.  Simulation  by  simulation  the  scripts  defined  in 
the  detailed  design  are  tested  to  ensure  that  the  times  to  execute  are  correct,  that  entities 
end  up  in  the  correct  locations,  that  expected  interactions  can  take  place  between  entities 
within  and  across  simulations  based  upon  the  results  of  the  scripts.  The  scripts  are  tested 
within  the  simulation  and  then  across  all  simulations  required  to  execute  a  mission  and 
theme.  The  final  testing  is  to  verify  that  each  mission  thread  can  be  executed,  that  themes 
and  mission  exhibit  the  appropriate  amount  of  capability  for  free  play  and  that  the  data 
collection  points  can  be  realized. 

Verify  Filters 

In  this  step  the  filters  are  tested  in  the  context  of  a  fully  federated  simulation  to  ensure  that 
the  filters  provide  the  desired  behaviour. 

Verify  C2  Interactions 

This  step  involves  testing  that  each  of  the  C2  interfaces  work  as  required  by  the  scenario.  It 
needs  to  verify  that  RADARS  pick  up  only  the  objects  that  should  be  seen,  control  loops 
between  C2  and  simulated  entities  function,  etc. 


UNCLASSIFIED 


27 


UNCLASSIFIED 

DSTO-TN-1300 

Verification  Review 

The  outcome  of  the  verification  and  validation  is  an  assessment  of  the  readiness  for  the 
simulation  to  support  the  experimental  objectives.  This  review  should  occur  before  the 
Experiment  Readiness  Review. 

2.6.1  Distributed  Simulation  Verification  and  Validation  Products 

The  Verification  and  validation  activities  generate  the  following  products:  a  detailed  set  of 
test  procedures  that  describe  how  to  execute  the  test  plan  developed  in  the  detailed  design 
stage;  all  necessary  test  scripts  and  scenarios  required  to  execute  the  tests;  the  test  results 
and  any  remediation's  and  retesting  that  resulted  from  executing  the  tests;  any  updates  to 
the  various  configuration  files  and  finally  a  statement  of  simulation  readiness. 

2.7  Summary 

The  coalition  implemented  the  preliminary  design  [section  2.4]  portion  of  the  method 
during  CAGE  IIIA.  Australia  implemented  the  preliminary  design  [Section  2.4]  and  an 
initial  pass  through  the  detailed  design,  implementation  and  V&V  phases  focusing  on 
execution  and  not  product  development  due  to  time  and  resource  constraints. 

The  simulation  infrastructure  developed  for  CAGE  IIIA  represented  a  quantum 
improvement  over  the  CAGE  II  implementation.  This  was  the  result  of  significant  fault 
finding  and  debugging  along  with  the  more  mature  design  approach  leveraged  for  the 
simulation. 


3.  Conclusions  and  Recommendations 


Technical  Panel  8  of  the  Joint  Systems  Analysis  group  under  The  Technology  Cooperation 
Program  (TTCP  JSA  TP8)  has  been  tasked  to  leverage  the  CAGE  campaign  to  develop  an 
addendum  to  the  Guide  to  Experimentation  (GUIDEX)  that  focuses  on  the  pragmatics  of 
distributed  experimentation  and  to  develop  a  distributed  simulation  design  methodology. 
The  aim  of  this  effort,  to  develop  a  distributed  simulation  design  methodology,  is  to 
extend  the  existing  standards  approach  from  addressing  an  Acknowledged  System-of- 
Systems  to  addressing  a  Directed  System-of -Systems. 

Within  CAGE  there  is  no  central  design  authority,  but  rather  a  federation  of  systems 
owned,  developed  and  operated  by  each  nation  with  an  agreed  upon  purpose,  i.e.  a 
Acknowledged  System  of  Systems  (SoS)  [DoD  OSD  2008].  Standards  such  as  Federation 
Development  and  Execution  Process  (FEDEP),  Synthetic  Environment  Development  and 
Exploitation  Process  (SEDEP),  Distributed  Simulation  Engineering  and  Execution  Process 
(DSEEP)  and  Kweley  and  Wood  all  assume  a  central  design  authority  and  thus  full  control 
of  the  system  of  systems  i.e.  a  Directed  SoS  [DoD  OSD  2008]  that  result  from  the 
federation. 
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" there  is  a  fundamental  requirement  to  ensure  each  nation  retains  control  of  their  simulations, 
while  federating  at  execution  time  in  a  peer-to-peer  manner". 


CAGE  IIIA  successfully  implemented  a  fully  distributed,  federated  simulation 
environment  that  stimulated  each  nation's  C2  systems  in  the  form  of  an  Acknowledged 
System  of  Systems.  Each  nation  was  responsible  for  building  their  own  simulation 
environment  for  their  area  of  operation.  The  national  simulations  environments  were  then 
federated  together  enabling  entities  to  move  across  areas  of  operation  and  to  be  available 
in  the  other  nation's  simulations. 

The  challenge  for  the  CAGE  campaign  of  experiments  is  to  continue  to  build  upon  this 
methodology  both  refining  the  deliverables  but  building  templates  for  the  deliverables 
and  remediated  simulation  environments  that  will  result  in  better  and  faster 
implementation  of  the  simulation  federation.  The  linkage  between  the  other  streams  of 
work  associated  with  building  an  experiment  requires  significant  improvement.  This 
methodology  is  principally  based  upon  a  waterfall  approach  whereas  the  experiment 
design  is  based  on  an  iterative  wave  model.  Getting  the  right  linkages  and  in  a  timely 
manner  is  a  work  in  progress. 

Another  challenge  is  the  development  of  an  optimal  level  of  scripting  and  allocation  of 
entities  to  simulations  to  enable  the  evolving  concept  of  trail  based  approach  to  CAGE 
events. 

The  distributed  simulation  design  methodology  developed  through  CAGE  IIIA  and 
presented  in  this  report  has  demonstrated  sufficient  utility  and  robustness  that  it  should 
continue  to  be  used  and  developed  in  both  the  CAGE  campaign  of  experiments  and 
similar  exercises/ experiments  that  exploit  distributed  federated  simulations. 


UNCLASSIFIED 


29 


UNCLASSIFIED 

DSTO-TN-1300 

References 

IEEE  Std  1730-2010  IEEE  Std  1730-2010,  IEEE  Recommended  Practice  for  Distributed 
Simulation  Engineering  and  Execution  Process  (DSEEP),  IEEE  Press  Piscataway  NJ,  2010. 

Andreas  Tolk  et  al.  (2012),  Engineering  Principles  of  Combat  Modeling  and  Distributed 
Simulation,  Wiley  Press,  Hoboken  New  Jersey. 

Jessee,  S.,  Hill,  A.,  Flahive,  A.,  The  TTCP  Coalition  Attack  Guidance  Experiment  (CAGE  II) 

Final  Report,  TR-AER/JSA-1-2013,  2013. 

O'Neill  J.  et.al.  2013  Cage  IIIA  Quicklook  -  Coordination,  Synchronisation  and  Deconfliction 
across  Joint  Fires,  Targeting,  Intelligence  and  ISREW,  DSTO-CR-2013-0360. 

DoD  OSD  Systems  Engineering  Guide  for  Systems  of  Systems,  Washington,  D.C.:  Office  of  the 
Deputy  Under  Secretary  of  Defense  for  Acquisition  and  Technology,  Systems  and 
Software  Engineering.  Systems  Engineering  Guide  for  Systems  of  Systems,  Version  1.0. 
Washington,  DC:  ODUSD(A&T)SSE,  2008. 


30 


UNCLASSIFIED 


Page  classification:  UNCLASSIFIED 


DEFENCE  SCIENCE  AND  TECHNOLOGY  ORGANISATION 
DOCUMENT  CONTROL  DATA 


1.  DLM/ CAVEAT  (OF  DOCUMENT) 


2.  TITLE 

CAGE  IIIA  Distributed  Simulation  Design  Methodology 


4.  AUTHOR(S) 

Dave  Bowen,  Michael  Galister,  Michael  Slade  and  John  O'Neill 


3.  SECURITY  CLASSIFICATION  (FOR  UNCLASSIFIED  REPORTS 
THAT  ARE  LIMITED  RELEASE  USE  (L)  NEXT  TO  DOCUMENT 
CLASSIFICATION) 

Document  (U) 

Title  (U) 

Abstract  (U) 


5.  CORPORATE  AUTHOR 

DSTO  Defence  Science  and  Technology  Organisation 
506  Lorimer  St 

Fishermans  Bend  Victoria  3207  Australia 


6a.  DSTO  NUMBER 
DSTO-TN-1300 


6b.  AR  NUMBER 
AR-015-959 


6c.  TYPE  OF  REPORT 
Technical  Note 


7.  DOCUMENT  DATE 
May  2014 


8.  FILE  NUMBER 

9.  TASK  NUMBER 

10.  TASK  SPONSOR 

11.  NO.  OF  PAGES 

12.  NO.  OF  REFERENCES 

07/294 

VCDF 

30 

5 

13.  DSTO  Publications  Repository 

http:/ / dspace.dsto.defence.gov.au/dspace/ 


15.  SECONDARY  RELEASE  STATEMENT  OF  THIS  DOCUMENT 


14.  RELEASE  AUTHORITY 

Chief,  Joint  and  Operations  Analysis  Division 


Approved  for  public  release 


OVERSEAS  ENQUIRIES  OUTSIDE  STATED  LIMITATIONS  SHOULD  BE  REFERRED  THROUGH  DOCUMENT  EXCHANGE,  PO  BOX  1500,  EDINBURGH,  SA  5111 _ 

16.  DELIBERATE  ANNOUNCEMENT 

No  Limitations 

17.  CITATION  IN  OTHER  DOCUMENTS  Yes 

18.  DSTO  RESEARCH  LIBRARY  THESAURUS 

Simulations,  Distributed  simulation 

19.  ABSTRACT 

While  there  is  a  considerable  body  of  scientific  knowledge  on  the  principles  for  designing  simulations,  there  is  a  gap  in  translating  these 
principles  into  the  pragmatics  for  designing  large-scale,  distributed,  peer-to-peer  federated  simulations  at  the  coalition  level.  CAGE  IIIA 
successfully  implemented  a  fully  distributed,  federated  simulation  environment  that  stimulated  each  nations  C2  systems.  This  report 
describes  the  Distributed  Simulation  Design  methodology  that  was  developed  and  trialled  by  DSTO  during  the  CAGE  IIIA  experiment 
to  enable  the  pragmatics  of  designing  &  implementing  a  fully  distributed,  federated  simulation  environment. 


Page  classification:  UNCLASSIFIED 


